DCOM95, Version 1.1 Release Notes Last Modified: October 16, 1997 DCOM95, Version 1.1, adds support for DCOM to Microsoft Windows 95. Please note the following instructions, guidelines, and features new to this release of COM and OLE functionality for Windows 95. If you are considering using DCOM95 on a pre-release version of Windows 98, please read the Installation Notes below before installing DCOM95. Distributed COM (DCOM) extends the Component Object Model (COM) infrastructure, transparently and naturally adding support for reliable, secure, and efficient communication between COM components such as ActiveX Controls, scripts, and Java applets residing on different machines in a LAN, a WAN, or on the Internet. With DCOM, your application can be distributed across locations that make the most sense to your customer and to the application. For more in-depth information, please read the DCOM Technical Overview, available on the Microsoft COM Home Page, http://www.microsoft.com/com/. Contents ======== I. Installation Notes A. Downloading and Extracting DCOM95 B. Before You Install DCOM95 C. Uninstalling DCOM95 II. Release Notes A. What's New in 1.1 B. Bug Fixes in 1.1 C. Known Issues D. Differences from Internet Explorer 4.0 and Windows 98 E. DCOM95 File List III. Developer Notes A. What's New in 1.1 B. Bug Fixes in 1.1 Affecting Developers C. Known Issues Affecting Developers D. Differences from DCOM on Windows NT E. Redistributing DCOM95 F. Support & Resources ********************************************************************** I. INSTALLATION NOTES A. Downloading and Extracting DCOM95 ------------------------------------ If you have downloaded this release of DCOM95 from a Web site, you should read the release notes completely before you extract and install DCOM95. After downloading DCOM95, you will have one or two compressed executable files on your hard drive: - DCOM95.EXE contains the COM system dlls - DCM95CFG.EXE contains the DCOM Configuration utility To extract either file and begin the installation process, type the file name at the Command Prompt or double-click the file from Windows Explorer. After running DCOM95.EXE, you will be prompted to reboot your system to complete the installation. Your existing OLE and COM system components will be saved to allow you to uninstall DCOM95 if necessary. If you run these programs on any version of Windows NT, no system components will be overwritten. You may be asked to reboot your system in order for changes to take effect; this is not necessary, as nothing as been changed. ---------------------------------------------------------------------- B. Before You Install DCOM95 ---------------------------- The DCOM95 installation program updates your system dlls. We recommend that you save all open documents and close all programs before installing DCOM95. This version of DCOM95 should work with existing and future versions of Windows 98. However, it has not been tested extensively with Windows 98, and is not a supported configuration at this time. If you elect to install this software over Windows 98 and run into any problems with your system, please uninstall DCOM95 1.1 and verify the problem still exists before attempting to get support on Windows 98. Please check the COM Home Page, http://www.microsoft.com/com/, and the Windows 98 release notes for information about using DCOM95 1.1 with Windows 98. If you are using Windows 98 with this version of DCOM95, please note the version of Windows 98 you are using when submitting feedback or bug reports about DCOM95. ---------------------------------------------------------------------- C. Uninstalling DCOM95 ---------------------- You can uninstall DCOM95 from the Windows Control Panel "Add/Remove Programs" applet. In the list at the bottom of the "Install/ Uninstall" tab, choose "DCOM for Windows 95" and press the "Add/ Remove" button. This will restore your previous OLE and COM system components. You will need to restart your computer to complete the uninstall. NOTE that if you install any applications that require DCOM95, performing an uninstall could adversely affect those applications. One application which you must be particularly careful with is Internet Explorer 4.0. Internet Explorer 4.0 ships with the DCOM95 dlls. If you install Internet Explorer before installing DCOM95, then you can safely uninstall DCOM95. If you install DCOM95 before installing Internet Explorer and wish to uninstall DCOM95, you should uninstall Internet Explorer first, then uninstall DCOM95, then reinstall Internet Explorer. This is particularly important if you have installed the Windows Desktop Update. ********************************************************************** II. RELEASE NOTES A. What's New in 1.1 ==================== This section lists the major new features of DCOM95 that are visible to end-users and administrators. Additional features for developers are described in the Developer Notes below. International Version --------------------- DCOM95 version 1.1 can now be installed over any localized version of Windows 95. DCOM95 1.1 does not include the OLE Common Dialogs (OLEDLG.DLL), which is the only portion of DCOM95 requiring localization. Note that the end-user license agreement (EULA), release notes, and setup prompts have not been localized. When you run DCOM95.EXE on a localized version of Windows, standard Windows buttons will be localized, but the remaining prompts will not. In addition, the DCOM Configuration utility, DCOMCNFG, is only provided in English in this web release. The program will work correctly on localized versions of Windows 95. Localized versions of Internet Explorer 4.0 and Windows 98 will include localized versions of the OLE Common Dialogs and the DCOM Configuration utility. Setup Improvements ------------------ There have been a few improvements to the DCOM95 setup program: - The DCOM95 installation program is now a windowless Windows program, so that it does not display a mysterious console window. All messages from the installation program use Windows message boxes or dialogs. - The setup program will detect if a later version of DCOM95 is installed and ask you to uninstall it before installing this version of DCOM95. - The setup program will retain the current values for the registry entries "EnableDCOM" and "EnableRemoteConnect", if they exist, rather than resetting to default values. - The setup program installs the redistribution agreement and release notes to %windir%\system\DCOM95. Winsock2 Compatibility ---------------------- The Winsock 2.0 release for Windows 95 would not install over DCOM95 1.0; this will not be a problem with DCOM95 1.1. DCOM95 1.1 is compatible with both Winsock 1.1 and Winsock 2.0. Client Support for Microsoft Message Queue ------------------------------------------ DCOM95 includes a new version of RPC that provides enhanced client-side support for RPC message queuing, which is a feature of Microsoft Message Queue Server (MSMQ). Updated DCOM Configuration Utility ---------------------------------- The DCOM Configuration Utility has been updated. In addition to a number of minor bug fixes, users may now enable or disable remote connections to a machine using DCOMCNFG. To let remote clients connect to servers on a machine, 1. Start DCOMCNFG on the machine 2. On the "Default Properties" page, check "Enable Distributed COM on this computer" 3. On the "Default Security" page, check "Enable Remote Connection" To prevent clients from connecting to servers on a machine, 1. Start DCOMCNFG on the machine 2. On the "Default Security" page, uncheck "Enable Remote Connection" Per-AppID Authentication Level ------------------------------ In certain circumstances, developers or administrators may wish to change the default authentication level used for all COM calls without calling CoInitializeSecurity. In DCOM95 1.0 and Windows NT, the only way to do this was to change the default authentication level specified in the registry on a machine-wide basis. With DCOM95 1.1, developers or administrators can specify the authentication level used per-Appid. To use this feature, 1. Start REGEDIT and locate the following key for your application: HKCR\APPID\ Note the AppID value in the right-hand pane. This will look something like: {0002DF01-0000-0000-C000-000000000046} 2. Now locate the AppID key for your application, using the AppID value from step 1: HKCR\APPID\ 3. Add a new DWORD value to this key by selecting the menu option "Edit|New|DWORD Value" with Name = "AuthenticationLevel" Data = 1 for no authentication -or- 2 for connect-level authentication ---------------------------------------------------------------------- B. Bug Fixes in 1.1 =================== This section describes bugs fixed in DCOM95 1.1 which affected applications running on Windows 95 with DCOM95 1.0 installed. Additional bug fixes are described in the Developer Notes section below. DCOM95 Uninstall: RPCLTC5.DLL Could Not Be Found ------------------------------------------------ When DCOM95 1.0 is uninstalled, it will always try to restore RPCLTC5.DLL and RPCLTS5.DLL from the %windir%\system\oldole directory. However, if the files were not already installed when DCOM95 is installed, the files will not be in the oldole directory, and you will see an error message about a missing file. If you select the "Skip File" option on the error dialog, DCOM95 1.0 uninstall will complete successfully. Windows 95 Setup only installs RPCLTC5.DLL and RPCLTS5.DLL if the NetBEUI protocol is installed. DCOM95 1.1 detects that the files are not installed, so that this error message does not occur during uninstall. DCOMCNFG Help Includes Windows NT Specific Features --------------------------------------------------- In DCOM95 1.0, the help file distributed in DCM95CFG.EXE included Windows NT specific features. DCM95CFG.EXE for DCOM95 1.1 includes an updated help file which is specific to Windows 95. Microsoft Outlook: External Add-ins and Extensions Cannot Be Loaded ------------------------------------------------------------------- If you are running Microsoft Outlook and you have DCOM95 1.0 installed, Outlook will be unable to load external extensions, and Outlook 97 may crash when you try to switch from the Tasks folder to the Contacts folder. This issue is fixed by DCOM95 1.1. Modal Dialog Box launched by OLE Server Hangs System ---------------------------------------------------- On systems with DCOM95 1.0 installed, if you are running an application that uses OLE and brings up a modal dialog box, the application may hang because the modal dialog box is unresponsive to mouse or keyboard input. This problem was reported: - when attempting to print a Microsoft Word 97 document which is hosted within Internet Explorer. The print dialog appears and neither the dialog nor Internet Explorer respond to mouse or keyboard input. - when attempting to send a mail message which contains spelling errors using Microsoft Outlook 97 when WordMail is used and spellchecking is enabled. After the WordMail spellchecker dialog is displayed, if you move the focus away from the dialog, neither Outlook nor the dialog respond to mouse or keyboard input. This problem is fixed by DCOM95 1.1. Visio: Corrupt Summary Information Causes Access Violation ---------------------------------------------------------- In certain instances, Visio incorrectly writes an empty thumbnail property in a document's Summary Information. The system property set implementation provided with DCOM95 1.0 detects that the property is written incorrectly, but does not handle the error correctly, resulting in an Access Violation. In DCOM95 1.1, the error is correctly handled. ---------------------------------------------------------------------- C. Known Issues =============== This section describes known problems in DCOM95 1.1 which affected applications running on Windows 95 with DCOM95 1.1 installed. Additional issues are described in the Developer Notes section below. Corel WordPerfect Suite 7: Installation Causes Invalid Page Fault ----------------------------------------------------------------- If you install Corel WordPerfect Suite 7 on a Windows 95 system running DCOM95, you may get an invalid page fault in PfOd70.pfc during installation. If this error appears, just close the error message dialog box. Setup should continue successfully. CyberLife Creatures 1.0: Does Not Function Correctly Without Upgrade -------------------------------------------------------------------- CyberLife Creatures 1.0 is not fully compatible with DCOM95. You will not be able to connect to the Creatures Web site from within Creatures, nor will all of the kits function correctly. These problems are addressed by the Creatures Upgrade Pack 2, which you can download from the Creatures Web site, http://www.cyberlife.co.uk/creatures_frameset.htm. Microsoft Access95: Database Replication Does Not Work ------------------------------------------------------ If you try to replicate an Access database using Microsoft Access95 on machines with DCOM95 installed, you may get the following error message: "Microsoft Access cannot complete this operation because it can't find or initialize the dynamic-link library Msjtrclr". This is a problem in Access95. You may workaround this issue by writing a program which uses the Access object model rather than the replica tool, or by using the briefcase for replication. Microsoft Access97 is not affected by this issue. Microsoft Dialup Networking: Version Conflict with SECUR32.DLL -------------------------------------------------------------- If you install Microsoft Dialup Networking from Windows 95 after installing DCOM95, you may see a file version conflict dialog for SECUR32.DLL: "Version Conflict : A file being copied is older than the file currently on your computer. It is recommended that you keep your existing file." File name: secur32.dll Description Microsoft Win32 Security Services Your version 4.10.1057 Do you want to keep this file? This is because DCOM95 includes a later version of SECUR32.DLL than shipped with Windows 95. If this error message occurs, select "Yes" to keep the file currently installed on your system. Microsoft Fax: Windows Messaging IPF on Shutdown ------------------------------------------------ On machines with DCOM95 and Microsoft FAX installed, an Invalid Page Fault occurs in AWFXCG32.DLL whenever Windows Messaging shuts down. This is due to memory corruption within Microsoft Fax. Since the error occurs as the process is exiting, you should be able to continue using your system without problem after dismissing the error dialog. Internet Explorer 4.0 and Windows 98 include an updated AWFXCG32.DLL which does not have this problem. Microsoft Object Packager: Loses Ability to Drag/Drop ----------------------------------------------------- On machines with DCOM95 installed, if you drag a file which does not have an associated OLE server and drop it into an OLE Document, the Object Packager will be invoked to insert a package into the document. In some cases, once you have done this, when you try to drag and drop another file, you will get an error message similar to "The server application, source file, or item cannot be found.....". Once you get this error message, you are not able to drag and drop objects again until you restart your machine. This seems to happen most often with large packages which are inserted into large documents. Microsoft PowerPoint: Fails to Insert an Excel 97 Object -------------------------------------------------------- If Autosave is enabled in Excel 97, PowerPoint 97 may fail to insert an Excel 97 object. Instead, the user will see the error message "PROBLEM: Error Message the Server is busy or not available". This is due to a combination of problems in Windows 95 COM and PowerPoint. The COM problem is fixed in DCOM95 1.1. An update for PowerPoint is also required to completely resolve the issue. Telcom Fax 3.1: Unable to Send Network Faxes -------------------------------------------- This product currently does not work with DCOM95 installed on Win95 client machines. Contact the manufacturer (http://www.ltc.com/) for information about Telcom Fax 4.0, which is compatible with DCOM95. Visio 1.0 Insert Object Fails ----------------------------- With DCOM95 installed, attempting to insert an object into a Visio 1.0 document may result in an error message: "An error (1331) occurred during the action Insert Object. The server failed to create the new document. "(Object Linking and Embedding)" This problem does not occur with later versions of Visio. ---------------------------------------------------------------------- D. Differences from Internet Explorer 4.0 and Windows 98 ======================================================== Internet Explorer 4.0 and Windows 98 both include updated COM dlls similar in functionality to DCOM95 version 1.1. This section describes the differences between the dlls included in these products. Internet Explorer 4.0 includes DCOM95 build 1120. Windows 98 beta 2 and beta 3 also include DCOM95 build 1120. DCOM95 version 1.1 (build 1718) contains a small number of fixes which are not in build 1120 for forward compatibility with forthcoming releases of Windows NT 5.0, Windows NT 4.0 Service Pack 4, and the COM Internet Services beta. In addition, these bugs are fixed in DCOM95 version 1.1, but not in build 1120: - RPCSS Page Fault in OLE32 When No Network Support Installed - 16-bit Server Crashes When Many Objects Are Created And Destroyed - MkParseDisplayName assumes MAX_PATH For information about differences between DCOM95 and future releases of Internet Explorer and Windows 98, please check the release notes for those products. ---------------------------------------------------------------------- E. DCOM95 File List =================== This table lists the version numbers of files distributed with DCOM95 1.0, DCOM95 1.1, and DCOM95 build 1120(as shipped with Internet Explorer 4.0 and Windows 98 beta 2 or beta3). File Name DCOM95 1.0 DCOM95 1.1 Build 1120 ============= ============ ============ ========== comcat.dll 4.71.1454.1 5.0.1600.1 5.0.1555.1 compobj.dll 2.30.41.60 2.30.100.0 2.30.100.0 dcomcnfg.exe 5.0.1413.1* 5.0.1600.0* 5.0.1555.0 dcomcnfg.hlp -- -- -- dllhost.exe 4.71.426.0 4.71.1718.0 4.71.1120.0 iprop.dll 4.0.1381.3 4.0.1381.6 4.0.1381.6 ole2.dll 2.30.41.60 2.30.100.0 2.30.100.0 ole32.dll 4.71.430.0 4.71.1718.0 4.71.1120.0 olecnv32.dll 4.71.426.0 4.71.1718.0 4.71.1120.0 oledlg.dll 5.0.1454.1 n/s 5.0.1555.0 olethk32.dll 4.71.426.0 4.71.1718.0 4.71.1120.0 rpcltc1.dll 4.10.0.2000 4.71.1718.0 4.71.1120.0 rpcltc5.dll 4.10.0.2000 4.71.1718.0 4.71.1120.0 rpcltccm.dll 4.10.0.2000 4.71.1718.0 4.71.1120.0 rpclts5.dll 4.10.0.2000 4.71.1718.0 4.71.1120.0 rpcltscm.dll 4.10.0.2000 4.71.1718.0 4.71.1120.0 rpcltspx.dll 4.10.0.2000 4.71.1718.0 4.71.1120.0 rpcmqcl.dll n/s 4.71.1718.0 4.71.1120.0 rpcmqsvr.dll n/s 4.71.1718.0 4.71.1120.0 rpcns4.dll -- -- -- rpcrt4.dll 4.71.423.0 4.71.1718.0 4.71.1120.0 rpcss.exe 4.71.426.0 4.71.1718.0 4.71.1120.0 storage.dll 2.30.41.60 2.30.100.0 2.30.100.0 secur32.dll 4.10.0.1057 4.10.0.1057 4.10.0.1057** imagehlp.dll 4.0.1381.1 4.0.1381.1 stdole2.tlb 2.20.4111.1 2.20.4122.1 stdole32.tlb 2.10.3027.1 2.10.3027.1 oleaut32.dll 2.20.4111.1 2.20.4122.1 olepro32.dll n/s 2.20.4122.1 asycfilt.dll n/s 2.20.4122.1 msvcrt40.dll 4.0.0.5270* 4.0.0.5270* mfc40.dll 4.0.0.5277* 4.0.0.5277* * : included in DCM95CFG.EXE ** : only in Internet Explorer 4.0 -- : no version number n/s : not shipped ********************************************************************** III. DEVELOPER NOTES A. What's New in 1.1 ==================== Component Category Manager Features Folded into OLE32 ----------------------------------------------------- The Component Category Manager, COMCAT.DLL, functionality is now part of OLE32.DLL. This was done to improve performance. DCOM95 1.1 includes a COMCAT.DLL which forwards requests to OLE32.DLL, to handle applications which directly interact with COMCAT.DLL. IGlobalInterfaceTable Support ----------------------------- The IGlobalInterfaceTable interface added to Windows NT in SP3 is now supported in DCOM95 1.1. Please see the Platform SDK documentation for information about this interface. Improved Dialup (RAS) Support ----------------------------- DCOM95 1.0 did not work well over dialup connections. DCOM95 1.1 includes a number of fixes which let both calls and callbacks work over dialup connections. In particular, if a server machine gets a new IP address, DCOM95 1.1 clients will be able to talk to new DCOM servers on that machine, even if they have previously established connections to other DCOM servers on the machine using the old IP address. Also, if a DCOM95 1.1 server machine acquires a new IP address, remote clients over dialup connections will be able to resolve OXIDs and unmarshal interfaces. (Note that a client machine which receives callbacks is acting as a server.) However, the dialup connection must be established before the COM server process is started. New DCOM Protocol Version Number -------------------------------- The DCOM protocol version number is now 5.3. New RPC APIs ------------ The following APIs are now implemented in DCOM95 1.1: - RpcServerUseAllProtseqsEx - RpcServerUseAllProtseqsIfEx - RpcServerUseProtseqExA - RpcServerUseProtseqExW - RpcServerUseProtseqIfExA - RpcServerUseProtseqIfExW Please see the Platform SDK documentation for information about these APIs. New Storage API Stubs --------------------- Windows NT 5.0 introduces some new storage APIs, Stg*StorageEx(). These are implemented in DCOM95 to return E_NOTIMPL. RPCSS Changes ------------- RPCSS is used for remote communication between COM objects. DCOM95 attempts to delay launching RPCSS until it is truly necessary. There were several scenarios in DCOM95 1.0 in which RPCSS was not started by COM at the appropriate time. In DCOM95 1.1, all known scenarios which required pre-launching RPCSS.EXE have been fixed. You should no longer need to pre-launch RPCSS. In DCOM95 1.0, RPCSS.EXE was shut down when a user logged off. In DCOM95 1.1, this is not the case. RPCSS.EXE remains running across logon sessions. This is required to support applications such as Microsoft Message Queue Server (MSMQ) which run as services. Also, RPCSS.EXE no longer appears in the Windows 95 Task List. SetBlanket on IUnknown affects AddRef and Release calls ------------------------------------------------------- When secure reference counting is turned off, calling IClientSecurity::SetBlanket on IUnknown will now affect AddRef and Release calls. ---------------------------------------------------------------------- B. Bug Fixes in 1.1 Affecting Developers ======================================== This section lists additional bug fixes in DCOM95 1.1 which are not likely to affect end-users, but which developers or testers might encounter. 16-bit Server Crashes When Many Objects Are Created And Destroyed ----------------------------------------------------------------- When thousands of 16-bit COM objects were created, marshaled to another apartment, then destroyed within a short period of time (< 2 minutes), a stack fault would occur in the server when DCOM cleaned up its internal list of object IDs (OIDs). The OID cleanup code has been modified so it does not cause a stack fault. Access Violation When In-Process Server Fails to Load ----------------------------------------------------- In certain situations, DCOM95 1.0 was not able to detect that an in-process server was not loaded successfully, because GetLastError() was not returning the correct error code after LoadLibraryEx() failed. An access violation would occur when attempting to access the server. DCOM95 1.1 detects this situation and returns ERROR_BAD_EXE_FORMAT when the server is loaded. Class Moniker Not Registered Correctly -------------------------------------- In DCOM95 1.0, the PROGID for the Class Moniker was not added to the registry during setup. This would prevent MkParseDisplayName from recognizing a moniker display name "clsid:". DCOM95 1.1 correctly adds the Class Moniker PROGID to the registry during setup. COMCAT: Category [Un]Registration Under a Non-Existant CLSID Succeeds --------------------------------------------------------------------- In DCOM95 1.0 and previous versions of COMCAT.DLL, registering and unregistering implemented or required class categories for a non-existant CLSID succeeded. In DCOM95 1.1, attempts to register or unregister categories for a non-existant CLSID fail. COMCAT: GetCategoryDesc Returns Wrong LCID ------------------------------------------ In DCOM95 1.0 and previous versions of COMCAT.DLL, when the description of a category for the specified LCID is not found, the returned description will be for the first locale under the category, but the returned LCID is not updated to the first locale value. This is corrected in DCOM95 1.1. COMCAT: IEnumXXX::Next() Succeeds Unexpectedly ---------------------------------------------- In DCOM95 1.0 and previous versions of COMCAT.DLL, the Next method of IEnumCATEGORYINFO, IEnumCATID, and IEnumCLSID succeeds when the caller passes pceltFetched NULL and celt > 1. In DCOM95 1.1, these methods match the specified behavior, which is to fail. DllCanUnloadNow/CoFreeUnusedLibraries Race Condition ---------------------------------------------------- Under certain circumstances, it was possible for COM to try to unload in-process COM servers which were already unloaded. This would generally cause a page fault. This has been fixed in DCOM95 1.1. IStorage::SetElementTimes Does Not Marshal NULL Parameters Correctly -------------------------------------------------------------------- If one or more parameters are set to NULL in a call to IStorage::SetElementTimes on a storage object obtained by standard marshaling, SetElementTimes returns RPC_X_NULL_REF_POINTER (0x800706f4). The interface definition of IStorage has been modified to handle NULL parameters correctly. NOTE that this means marshaling does not work correctly to a machine which is running Windows NT 4.0 SP3 or earlier, Windows 95, or Windows 95 with DCOM95 1.0. Windows NT 4.0 SP4, Windows NT 5.0, and Windows 98 will be compatible with DCOM95 1.1. Marshaling Problems ------------------- In DCOM95 1.0, big-endian values and Variants were not always marshaled correctly. These problems have been fixed in DCOM95 1.1. MkParseDisplayName assumes MAX_PATH ----------------------------------- MkParseDisplayName assumed any kind of moniker it did not recognize was a file moniker and thus that the maximum length of the display name was MAX_PATH characters. If the display name was really longer than MAX_PATH characters, the stack would be corrupted and the client which called MkParseDisplayName would crash. MkParseDisplayName now makes no assumptions about the maximum length of a moniker display name. Remote COM Calls Fail Because RPCSS is not Started -------------------------------------------------- In DCOM95 1.0, there were a number of scenarios where RPCSS was not started at the appropriate time, causing remote COM calls to fail. All known scenarios which required pre-launching RPCSS.EXE have been fixed in DCOM95 1.1. RPCRT4.DLL Leaks Memory When Loaded and Unloaded Within a Process ----------------------------------------------------------------- If RPCRT4.DLL was repeatedly loaded and unloaded within a running process, system memory functions such as HeapCreate and CreateThread would start failing, due to a memory leak in RPCRT4. This has been fixed. RPCSS Assumes All Servers On Same Machine Speak The Same Protocol ----------------------------------------------------------------- Assume a client C1 on machine C starts talking to a server X on machine S via protocol P1. Now another client C2 (also on machine C) comes along that wants to talk to server Y on machine S via protocol P2. This did not work correctly - RPCSS on C assumed that all servers on S would speak the same protocol (P1) using the same endpoints and did not correctly handle the binding information needed to speak to S. This could lead to crashes on the client machine. Although DCOM95 currently only supports one protocol, this has been fixed for forward compatibility with the COM Internet Services (which introduces a second protocol) and Windows NT 5.0 (which lets you specify which endpoints to use for different servers). RPCSS Can Not Restart After a Crash ----------------------------------- In DCOM95 1.0, RPCSS cached information in shared memory, preventing RPCSS from being restarted if it crashed. RPCSS no longer caches information in shared memory, so it can be restarted. RPCSS Page Fault in OLE32 When No Network Support Installed ----------------------------------------------------------- If RPCSS.EXE was launched for any reason on machines without network support installed, a page fault in OLE32.DLL might occur. The RPCSS startup code has been cleaned up to handle scenarios like this in DCOM95 1.1. System Property Set Implementation Leaks Memory ----------------------------------------------- Applications that retrieve property values from property sets using the system-provided property set implementation exhibit a gradual increase in memory usage. The IPROP.DLL included with DCOM95 1.1 fixes this problem. System Property Set Implementation Loses Part of DocumentSummaryInfo -------------------------------------------------------------------- With DCOM95 1.0 and previous versions of IPROP.DLL, when a client uses the system-provided property set implementation to create the user-defined properties in a DocumentSummaryInfo property set, the primary section of the property set is lost. This is because the system implementation deletes any existing streams when a property set is created. The IPROP.DLL included with DCOM95 1.1 correct handles creating all sections of DocumentSummaryInfo and SummaryInformation property sets. WM_TIMERs fill queue on long call --------------------------------- In DCOM95 1.0, COM or RPC calls which took a long time to complete could generate WM_TIMER messages but not dispatch them, filling the application's message queue and consuming space in the 16-bit heap. This could cause system response problems and instability. This is fixed in DCOM95 1.1. ---------------------------------------------------------------------- C. Known Issues Affecting Developers ==================================== AutoDial Dialog May Appear Unexpectedly --------------------------------------- If AutoDial is enabled on a Windows 95 machine with DCOM95 installed, the AutoDial dialog may appear when a remote object is accessed via DCOM, even if the remote machine is accessible without establishing a dialup connection. If you cancel the AutoDial dialog, the call to the remote object will succeed. Compiler Errors --------------- There are two issues that can result in the "'xxx' is not a member of _COSERVERINFO" and "'CoInitializeEx' (or 'CoCreateInstanceEx'): undeclared identifier" compilation errors while building DCOM programs. One is caused by out-of-date headers that expose the changes of the definition of the COSERVERINFO structure from Windows NT 4.0 Beta 1. In order to support the ActiveX SDK Beta, Microsoft Visual C++r 4.2 shipped with headers from Beta 1 of Windows NT 4.0. These have an earlier and incorrect version of the COSERVERINFO structure definition. To work around this problem, install the final Windows NT 4.0 SDK and put its include, lib, and bin directories first on your tool paths. A patch to Microsoft Visual C++r 4.2 is also available at http://www.microsoft.com/visualc/patches/v4.2b/vc42b.htm which updates these headers. A second issue revolves around the need for pre-processor definitions to allow access to DCOM-only features in the Win32 header files. The DCOM features in the Windows NT 4.0 SDK (and in the Microsoft Visual C++ 4.2 + patch headers) are protected by two preprocessor definitions. One of these, setting _WIN32_WINNT=0x0400, is used for targeting applications for Windows NT 4.0. Use this setting if you are building a DCOM-aware application for Windows NT 4.0 only. Note that this setting is automatically established by the makefile helper that comes with the SDK when you use TARGETOS=WINNT and use "!include ". The other setting, _WIN32_DCOM, is used for targeting applications for Windows 95 (with DCOM installed) as well as Windows NT 4.0. Use this to build DCOM applications for both platforms without making use of Windows NT-specific features. If you don't use one of these two settings, the compiler will warn you or halt with errors about structures and APIs that you use that are specific to Windows NT 4.0 or DCOM for Windows 95. Applications using CLSCTX_SERVER/CLSCTX_ALL do not run on plain Windows 95 or previous versions of Windows NT if compiled with _WIN32_DCOM or _WIN32_WINNT>=0x0400. The new definitions of CLSCTX_SERVER and CLSCTX_ALL include CLSCTX_REMOTE_SERVER. Applications using these flags will not run on plain Windows 95 or previous versions of Windows NT when compiled as instructed, above, with the _WIN32_WINNT=0x0400 or _WIN32_DCOM flags. Previous versions of COM/OLE validate the flags passed to CoCreateInstance or CoGetClassObject and fail with E_INVALIDARG when CLSCTX_REMOTE_SERVER is specified. When targeting both Windows NT 4.0 and Windows 95 or previous versions of Windows NT, you need to ensure that the _WIN32_WINNT preprocessor symbol is defined to be less than 0x0400 and the _WIN32_DCOM preprocessor symbol is not defined. DCOM Dialup Connections Don't Work When Ethernet Card is Stopped ---------------------------------------------------------------- In situations where an ethernet card is used, the card is stopped, and then a dialup (RAS) connection is established, DCOM calls may fail or crash. Dialup Connections Do Not Work to Running Servers ------------------------------------------------- If a COM server is running on a DCOM95 server machine before a client establishes a dialup (RAS) connection to the server machine, the remote client will not be able to talk to the COM server over the RAS connection. IAccessControl::IsAccessAllowed Erroneously Denies Access --------------------------------------------------------- IAccessControl::IsAccessAllowed uses the API NetAccessCheck() to determine whether a users is allowed access. In some cases, NetAccessCheck returns the wrong value, causing IsAccessAllowed to return the wrong value as well. Receiving OR_INVALID_OXID (0x80070776) -------------------------------------- When using COM creation APIs (such as CoCreateInstance, CoCreateInstanceEx, or CoGetClassObject) to create remote objects (objects on other machines), incorrectly configured network settings that otherwise appear to support file or print sharing properly may cause Distributed COM to fail with the distinguished error, OR_INVALID_OXID (0x80070776). This is typically not a problem with COM, but is simply a network configuration problem that is not exposed by other networking operations that have different fall-back behavior from COM over improperly configured protocols. A common occurrence of this failure is when a machine has been configured with TCP/IP as well as another network transport, such as IPX/SPX, or NetBeui, but the TCP/IP configuration is improperly configured. For example, it may be configured to be dynamically assigned an IP address using DHCP, yet no DHCP server may be available and so it has no IP address. The solution to this problem is to properly configure TCP/IP networking. A test that TCP/IP networking is properly configured is to use the PING command to test the connection between the client and the server. That is: From the client: PING From the server: PING If either PING command fails with errors such as "Bad IP address " or "Request timed out," you may experience difficulties creating remote objects until the issue preventing the connection is resolved. TreatAs on Remote Server ------------------------ During a remote activation for a specific class, the server side does not correctly use the TreatAs mappings: Although the correct server process gets connected to, COM still expects the original CLSID instead of the mapped CLSID. If the server does not provide a class factory (through CoRegisterClassObject) for the original CLSID, the activation times out after 30 seconds. Two Identical FORMATETC's on Clipboard Seen As One -------------------------------------------------- If a data object is created with two identical FORMATETC formats, or two FORMATETC formats which differ only in their aspect, and the data object is set to the clipboard, when you get the data object from the clipboard and enumerate its formats, there is only one FORMATETC. VREDIR BlueScreen During CoCreateInstance ----------------------------------------- When using DCOM between a DCOM95 machine and an Windows NT machine in a Novell Netware workgroup, if you map a drive letter on the DCOM95 machine to a shared directory on the Windows NT machine, you may get a blue screen in VREDIR during CoCreateInstances call on the DCOM95 client machine. The problem does not occur if you don't have mapped drives. The system can recover from the blue screen if you hit enter. This problem has only been seen with the original Windows 95 release, not with OSR2 or later. A hotfix for VREDIR.VXD is available from Microsoft to correct this problem. ---------------------------------------------------------------------- D. Differences from DCOM on Windows NT ====================================== Security Capabilities of DCOM for Windows 95 -------------------------------------------- The core functionality and application programming interfaces (APIs) new to Distributed COM are identical in both Windows 95 and Windows NT 4.0; however, certain capabilities related to security are different because of the different security infrastructures of the operating systems. Using the default security settings of the system is recommended; it is also necessary to enable "user-level" security on file-system shares (see below). The following services, which can be used to override default security, are available: - CoInitializeSecurity - CoQueryAuthenticationService - CoQueryProxyBlanket - CoSetProxyBlanket - CoQueryClientBlanket - IClientSecurity Interface - IServerSecurity Interface However, certain capabilities that are part of DCOM for Windows NT 4.0 will not be available on Windows 95 because of differences in the security infrastructure on Windows 95. In particular, the lack of Win32 security APIs, such as the ability to create Access Control Lists (ACLs), and the AccessCheck function, as well as the lack of a security context associated with thread- and process-tokens, should be taken into account. Windows 95 does not natively support these APIs or constructs. Because of this, DCOM95 will not support impersonation (specifically, the CoImpersonateClient and CoRevertToSelf helper functions over the IServerSecurity interface), which is based on thread- and process-token security in Windows NT 4.0. Impersonation is commonly used to automatically control access to restrictable system resources such as the file system, other processes, and the network. These resources are not restrictable on Windows 95. DCOM95 does, however, offer programmers various helper objects to provide access-control-list and access-check functionality, which can be used to explicitly control access by remote clients to both system and user-defined resources or data. These helper objects are provided by the system object CLSID_DCOMAccessControl, which implements the IAccessControl interface. IAccessControl should be used to manage security permissions programmatically wherever portability between Windows 95 and Windows NT is a concern. The CLSID_DCOMAccessControl object is available in all releases of DCOM95 and in Windows NT 4.0 SP2 or later. Please see the Platform SDK documentation for more information about IAccessControl. Launch and Access Security -------------------------- "Launch security" -- controlling who can launch server-class code -- is not provided in DCOM for Windows 95 because launching servers is not supported. Servers/Classes must already be running in order for remote clients to connect and make use of their services. DCOM95 does support the ability to connect to already running classes/servers. "Access security" is supported via the \APPID\{.}\AccessPermissions registry key and adjusted via the DCOMCNFG tool or during installation or setup of the server code. Unauthenticated users will be able to use servers if you configure the class to support unauthenticated connections (through static configuration tools or dynamically via the CoInitializeSecurity function) and you can also build arbitrary access-control lists to define which users and groups can access specific services. Authentication Levels --------------------- DCOM95 clients can make DCOM calls using any authentication level. DCOM95 servers (or clients receiving callbacks) can only accept DCOM calls using RPC_C_AUTHN_LEVEL_NONE or RPC_C_AUTHN_LEVEL_CONNECT authentication levels. Transports ---------- DCOM95 only supports TCP connectivity. If you do not have the TCP/IP protocol installed, DCOM95 will not be able to support cross-machine COM. Registry Settings ----------------- The following registry keys found under HKEY_LOCAL_MACHINE\Software\Microsoft\OLE are established by DCOM95. EnableDCOM (default value = "Y") Enables Distributed COM on this machine. When set to "N", the machine is prevented from connecting to or activating objects on remote machines, and remote machines are unable to connect to objects on the local machine. Setting this value to "Y" enables either connectivity as a client to remote objects (when EnableRemoteConnect='N', see below), or full client/server connectivity (when EnableRemoteConnect='Y', see below). EnableRemoteConnect (default value = "N") Enables COM servers to act as DCOM servers. When this value is set to "Y", references to interfaces on local objects can be passed to remote clients, and remote clients are allowed to connect to running objects. When this value is set to "N", this machine is allowed to connect to remote objects but cannot act as a server -- that is, the machine is prevented from connecting to running objects. In addition, the following registry key is found under HKEY_CLASSES_ROOT\CLSID: {bdc67890-4fc0-11d0-a805-00aa006d2ea4}\InstalledVersion Contains the version number of DCOM for Windows 95, in the format "a,b,c,d". This value can be used by Internet Component Download to determine whether DCOM95 is installed. This value is added to the registry during setup, and should not be modified. Using Windows 95 as a DCOM Server Host -------------------------------------- Windows 95 can be a DCOM server host with the following caveats: 1. There is no launch capability which means the DCOM server process must be already running for a client to connect to it. 2. If secure connections are needed, then the server (and in the case of callbacks, the client) must have user-level access control with the name of a security provider set. 3. The registry value "EnableRemoteConnect" must be set to "Y". DCOM95 has been tested most extensively using the Windows NT Domain security provider. You may encounter problems using other security providers. To establish user-level access control, you must have FILESEC.VXD installed. This is generally installed on Windows 95 machines by installing File and Print Sharing. To enable user-level access control, launch the Network control panel applet, choose the "Access Control" tab, check the box marked "User-level access control", and enter the name of your security domain. This may affect the way you currently share directories on the network from your computer; see the on-line documentation for details. If you do not have an "Access Control" tab in your network configuration control panel, you need to install a network client service. See the "Network clients, setting up" help topic in the on-line help for information on installing a network client. ---------------------------------------------------------------------- E. Redistributing DCOM95 ======================== If you depend on DCOM95 functionality, you have two options: redistribute the updated system files (DCOM95) with your application, or point users at our DCOM95 web release. Pointing users at the web release is recommended if your application will be downloaded from the web, since DCOM95 is fairly large and many users may already have it. For further information about redistributing DCOM95, please review the redistribution guidelines in DCOMDIST.TXT and the redistribution agreement in DCOMLIC.TXT. ---------------------------------------------------------------------- F. Support & Resources ====================== Paid Support ------------ DCOM95 application development is supported by Microsoft Technical Support. You can ask questions through your Premier Level support contract. You can also ask questions through your Priority Level contract or purchase individual Priority Support incidents (essentially a one-time fee for one question). If you would like to understand more about Microsoft's paid support options, you can call Microsoft Support Sales at (800) 936-3500 from 6:00 a.m. to 6:00 p.m. Pacific time, Monday through Friday, excluding holidays. Please note that technical support is not available through this number. Microsoft Technical Support Information is also available on the World Wide Web at http://www.microsoft.com/support/. Free Support ------------ Newsgroups are a great place for free peer support. As time and resources allow, Microsoft developers, program managers, support engineers, and test engineers visit the site to collect feedback and answer questions or correct misperceptions. There is no guarantee that you will receive a response from Microsoft to any newsgroup posting. The following newsgroups can be used to ask questions about DCOM95: - comp.os.ms-windows.programmer.ole - microsoft.public.win32.programmer.ole The DCOM mailing list is another good form of free peer support. An advantage to being on a mailing list is that this is where Microsoft will make early announcements of information on a given topic. Again, it is peer support, and Microsoft staff will often lurk there, but are not guaranteed to respond to any postings. To learn more about the DCOM mailing list, please review our Mailing List page at http://www.microsoft.com/sitebuilder/resource/mail.asp. Providing Feedback ------------------ Please send any comments or bug reports to the DCOM mailing list. Resources --------- You can find additional information about DCOM on the COM Home Page at http://www.microsoft.com/com/.